Automated management of software requirements verification

ABSTRACT

An exemplary system for electronically managing requirements for software development includes a projects module, a requirements module, a mapping module and a verification module. The projects module is configured to establish a software development project. The requirements module is configured to define requirements for the project based on requirements information captured from a requirements source. For each requirement, the projects module is configured to associate source code developed for the requirement with the project or assign the requirement for development of source code. The mapping module is configured to map procedures identified in the source code to the defined requirements. The verification module is configured to verify the defined requirements based on results of one or more of analyses, code coverage measurements and unit testing performed on the mapped procedures.

FIELD OF THE INVENTION

The present invention relates to management of software developmentrequirements. More particularly, the present invention relates toautomated techniques and tools for integration of distributedrequirements traceability and software testing/verification.

BACKGROUND

In many safety-critical and mission-critical industries, such as theavionics, medical, defense, and nuclear industries, among others,requirements traceability and verification tasks associated withsoftware development projects can consume a significant portion of theproject budget. Techniques exist for automatically capturingrequirements information for software development projects from varioussources of requirements information into the form of a requirementstraceability matrix (RTM), which can be used to trace the implementationof the requirements in source code. The RTM typically includesproject-level, customer-defined requirements that specify how thesoftware product should operate as well as low-level design constraints,but not code-level, verification requirements that specify how thesoftware product should be verified. Further, techniques exist formanually testing source code written to implement the requirements andfor verifying the requirements. What is needed, therefore, is atechnique for integrating and automating the requirements traceabilityand testing/verification tasks of a distributed software developmentproject, including a uniform user interface to help manage highlycomplex and technical software development projects.

SUMMARY

The present invention supports highly distributed and asynchronousoperations. Exemplary embodiments of the present invention, whichutilize a central depository, are inherently centralized and can bemanaged by administrators. Exemplary embodiments of the presentinvention link user workspaces and development artifacts in adynamically managed project tree, thereby synthesizing the processes andensuring their repeatability. The users return the software developmentartifacts to central repository. Thus, exemplary embodiments of thepresent invention establish and maintain demonstrable traceability.Accordingly, exemplary embodiments of the present invention can solvethe problems with related art systems, in which the processes performedare consequently largely manual, error prone and inconsistent. Thepresent invention is not limited to or required to solve the problems inrelated art.

An exemplary method for electronically managing requirements forsoftware development includes: establishing a software developmentproject; defining requirements for the project based on requirementsinformation captured from a requirements source; for each requirement,associating source code developed for the requirement with the projector assigning the requirement for development of source code; mappingprocedures identified in the source code to the defined requirements forthe project; and verifying the defined requirements for the projectbased on results of one or more of analyses, code coverage measurementsand unit testing performed on the mapped procedures.

An exemplary method for electronically managing requirements forsoftware development using extensible markup language (XML) includescreating an XML thread for each of a plurality of requirements definedfor a software development project. Each thread comprises a plurality ofelements that describe properties of the thread and a unique identifierthat enables traceability of the defined requirements for the project.The method also includes implementing XML wrappers to enableapplications to interface with the XML threads. The properties of eachXML thread include a corresponding defined requirement for the project,procedures of source code for the project that are mapped to thecorresponding defined requirement, and results of one or more ofanalyses, code coverage measurements and unit testing performed on themapped procedures.

An exemplary system for electronically managing requirements forsoftware development across a network of users includes a projectsmodule, a requirements module, a mapping module and a verificationmodule. The projects module is configured to establish a softwaredevelopment project. The requirements module is configured to definerequirements for the project based on requirements information capturedfrom a requirements source. For each requirement, the projects module isconfigured to associate source code developed for the requirement withthe project or assign the requirement for development of source code.The mapping module is configured to map procedures identified in thesource code to the defined requirements. The verification module isconfigured to verify the defined requirements based on results of one ormore of analyses, code coverage measurements and unit testing performedon the mapped procedures.

An exemplary system for electronically managing requirements forsoftware development across a network of users includes a project moduleconfigured to establish a software development project; a requirementmodule configured to define requirements for the project based onrequirements information captured from a requirements source; a modelingmodule configured to include architectural artifacts and implementationartifacts; and a verification module configured to verify the definedrequirements for the project based on results of one or more of tests inaccordance to one or more verification rules. The module links thedefined requirements to architectural artifacts and implementationartifacts of the modeling module.

An exemplary method for electronically managing requirements forsoftware development includes establishing a software developmentproject; defining requirements for the project based on requirementsinformation captured from a requirements source; establishing a modelingmodule that includes architectural artifacts and implementationartifacts; and verifying the defined requirements for the project basedon results of one or more of tests in accordance to one or moreverification rules. The defined requirements are linked to respectivearchitectural artifacts and implementation artifacts.

BRIEF DESCRIPTION OF THE DRAWINGS

Other objects and advantages of the invention will become apparent tothose skilled in the relevant art(s) upon reading the following detaileddescription of preferred embodiments, in conjunction with theaccompanying drawings, in which like reference numerals have been usedto designate like elements, and in which:

FIGS. 1A and 1B illustrate an exemplary environment in which a systemfor automatically managing software requirements verification can beimplemented and an exemplary embodiment of an automated requirementsverification tool, respectively;

FIG. 2 illustrates a process flowchart providing exemplary steps for amethod of automatically managing software requirements verification;

FIGS. 3A-3E illustrate an exemplary extensible markup language (XML)implementation of a system for automatically managing softwarerequirements verification;

FIGS. 4A-4J illustrate screen captures of an exemplary graphical userinterface of a system for automatically managing software requirementsverification.

FIG. 5 illustrates an example of selecting, creating, renaming ordeleting a group view;

FIG. 6 illustrates an example of editing rules for a given group;

FIG. 7 illustrates an example of parsing based on types;

FIG. 8 illustrates an example of requirements in an Microsoft(MS) Wordfile;

FIGS. 9 and 10 illustrate examples of a type editor;

FIG. 11 illustrates an example of ungrouped requirements and groupedrequirements;

FIG. 12 illustrates an example of a sibling requirement; and

FIG. 13 illustrates another example of a sibling requirement.

DETAILED DESCRIPTION System Overview

The present invention shall be described by way of exemplary embodimentsto which it is not necessary limited. Variations and modifications willoccur to these skilled in the art without departing from the scope ofinvention defined in the claims appended hereto. Absolute statements(that begin with, e.g., “must”), and statements of advantages or otheraspects apply to specific exemplary embodiments, and not necessarily toall embodiments covered by the claims.

Techniques for automated management of software requirements arepresented herein that can bridge the gap between high-level requirementstraceability tools and low-level source code testing tools across anetwork of distributed user workspace (e.g. work directories enabled byinstances of the invention). The explanation will be by way of exemplaryembodiments to which the present invention is not limited.

FIG. 1A illustrates an exemplary environment for implementing a system100 for automated management of software requirements verification. Asshown in FIG. 1A, the system 100 can be employed in conjunction with acomputer-based system, where the elements can be implemented inhardware, software, firmware, or combinations thereof. As shown in FIG.1A, system 100 includes a requirements information source 105, arequirements capture tool 110, an automated requirements verificationtool 115, a static analysis tool 120, a unit/integration test tool 125,a network 130, and users 135. Software development projects (e.g., abilling system for a hospital, an inventory tracking system for a store,an avionics display system, etc.) can be defined by requirements. Therequirements can specify how the software product should operate when itis implemented. The requirements information source 105, shown in FIG.1A, can represent any source of requirements information, includingrequirement management tools, e.g., Telelogic DOORS®, and IBM RationalRequisitePro®, spread sheet programs, e.g., Microsoft Excel®, wordprocessing programs, e.g., MS Word®, among other sources of requirementsinformation. The requirements capture tool 110, can be implemented tocapture the requirements information from the requirements informationsource 105. This information may include requirement identifier andrequirement description as well as test case identifier and test casedescription.

In one embodiment, the requirements capture tool 110 can use naturallanguage parsing to parse the requirements information. For example, arequirement capture tool, such as the Regtify™ tool from Geensys (on theweb at geensys.com) employs such techniques to generate a RTM fromrequirements information. Products, such as LDRA TBreq™, or customizedhand-coded systems can be employed to implement the requirements capturetool 110. The parsing of requirements can be performed based on types,as described in more detail below in the subsection entitled “ParsingBased On Types View.”

For example, if software is to be developed for an on-line grocerystore, the requirements information source might include an MS Word™document that specifies, among other requirements, “the on-line grocerystore shall maintain a customer account.” In this example, therequirements capture tool 110 might capture from the text of the MSWord™ document, the requirement information “maintain account.” Inanother example, the requirements information source might include aDOORS™ module that specifies, among other requirements, “the softwaremust provide fault isolation for all fault types.” In this example, therequirements capture tool 110 might capture from the text of the DOORS™module, the requirement information “Isolate faults.”

In an exemplary embodiment, a software modeling module 190 can be usedwith the requirement capture tool 110. The software modeling module 190can be implemented by a software modeling tool, such as TelelogicRhapsody™, Mathworks Simulink™ or National Instruments Labview™. In thisexemplary embodiment, the requirements capture tool 110 linksrequirements to architectural artifacts and implementation artifacts inthe software modeling tool 190. These architectural and implementationartifacts are thereby implicitly mapped to the resulting source codethat is produced by the modeling tool. Thus, each requirement isassociated with one or more software architectural model elements. Themodel elements are propagated to the distributed verification modulesfor the purposes of implementation, testing and analysis.

In addition, a modeling tool or a software architectural model can beused to automatically generate source code in which the mapping betweenrequirement and source code is made. In other words, the requirementslinked with the architectural and implementation artifacts areimplicitly mapped to resulting source code produced by the modelingtool.

If the software implementation is manually coded, the mapping ofrequirements to source code is performed using automated requirementsverification tool 115 based on the implementation artifacts produced bythe modeling tool. The automated requirements verification tool 115 willbe described below in detail.

The static analysis tool 120 can be implemented to analyze source codefiles, which have been written by software developers, to identifyprocedures in the source code and to assess compliance of the sourcecode with project coding rules and quality metrics. As referred toherein, a “procedure” describes a portion of source code written toimplement a requirement. For example, procedures might include functionsin the C programming language and classes and member functions in theC++ programming language. Automated software analysis and testingproducts, such as LDRA Testbed™; Coverity's (on the web at coverity.com)Coverity Prevent Coverity Extend; Programming Research's (on the web atprogrammingresearch.com) QA-C, QA-C++ and QA-MISRA; Gimple Software's(on the web at gimpel.com) PC-lint for C/C++ and another Lint basedproducts; Klocwork's (on the web at klocwork.com) inSpect, inSight,inTellect and inForce; Parasoft's (on the web at parasoft.com) C++ Test,C++ Test for Embedded Systems, Code Wizard and Jest with Test CaseSniffer; McCabe & Associates' (on the web at mccabe.com) McCabe IQ;Telelogic's Telelogic Logiscope, TAU/Tester and TAU/LogiscopeTestChecker; and Testwell's (on the web at testwell.fi) CMT++,Complexity Measures Tool for C/C++ can be employed to implement thestatic analysis tool 120.

For the on-line grocery store example, an exemplary source code file“MaintainAccount.c” for implementing the captured requirement “maintainaccount” might include the following lines of code:

  float MaintainAccountFunction( ) {  long accntNum;  float balance,avgBalance, ratio;  accntNum = GetSessionAccountNumber( );  if (accntNum== 0) {return −1; }  balance = GetAccountBalance(accntNum);  if (balance<= 0) { FatalError(“Balance too low”); }  avgBalance =GetAverageAccountBalance(accntNum);  ratio = balance / avgBalance;  if(ratio < .2)  {    UserMessage(“Balance is running low”);  }  return 0;}

In this example, the static analysis tool 120 might identify thefollowing basic blocks of source code (blocks 4-6):

60 4 balance = 61 4  GetAccountBalance 62 4  accntNum ) ; 63 4 if 64 4 ( 65 4  balance <= 0 66 4  ) 67 5  { 68 5 69 5   FatalError ( 70 5  “Balance too low” ) ; 71 5  } 72 6 avgBalance = 73 6 GetAverageAccountBalance ( 74 6  accntNum ) ; 75 6 ratio = balance /avgBalance ; 76 6 if 77 6  ( 78 6  ratio < .2 79 6  )

After analyzing the source code for compliance with project codingrules, the static analysis tool 120 might identify the following codefor non-compliance (M) Mandatory:

56 2  { 57 2   return 58 2   − 1 ; (M) STATIC VIOLATION: 101 S :Function return type inconsistent 67 5  { 68 5 69 5   FatalError ( 70 5  “Balance too low” ) ; (M) VIOLATION : 1 J : Unreachable Code found. 715  } 72 6 avgBalance = 73 6  GetAverageAccountBalance 74 6  accntNum ) ;75 6 ratio = balance / avgBalance ; 76 6 if 77 6  ( 78 6  ratio < .2 (M)STATIC VIOLATION : 96 S : Use of mixed mode arithmetic: float doubleratio < .2 79 6  )

For the avionics display system example, an exemplary source code file“CheckAvionicsDisplay.c” for implementing the captured requirement“maintain account” might include the following lines of code:

  intCheckAvionicsDisplay( ) {   // attempt to start modules. If amodule AND its backup fail,   // return a negative number indicating thefailed module.   //   if (!BITestModule1( )) { if (!BackupModule1( ))return −1; }   if (!BITestModule2( )) { if (!BackupModule2( )) return−2; }   if (!BITestModule3( )) { if (!BackupModule3( )) return −3; }  // everything started up. Return 1 to indicate success.   return 1; }

In this example, the static analysis tool 120 might identify thefollowing basic blocks of source code (blocks 1-7):

37 1 int 38 1  CheckAvionicsDisplay( ) 39 1  { 40 1 //attempt to startmodules. If a module & its backup fail 41 1 // return a negative numberindicating the failed module. 42 1 43 1   if 44 1    ( 45 1    ! 46 1    BITestModule1 ( ) 47 1    ) 48 2    { 49 2     if 50 2      ( 51 2     ! 52 2       BackupModule1 ( ) 53 2      ) 54 3      { 55 3      return 56 3       − 1 ; 57 4      } 58 5     } 59 6    if 60 6    ( 61 6     ! 62 6      BITestModule2 ( ) 63 6     ) 64 7     { 65 7     if 66 7       ( 67 7       ! 68 7        BackupModule2 ( ) 69 7      )

After analyzing the source code for compliance with project codingrules, the static analysis tool 120 might identify the following codefor non-compliance (M) Mandatory:

37 1 int 38 1  CheckAvionicsDisplay( ) (M) STATIC VIOLATION: 63 S Emptyparameter list to procedure/ funct. 39 1  { 40 1 // attempt to startmodules.If a module & its backup fail, 41 1 // return a negative numberindicating the failed module. 42 1     // 43 1   if 44 1    ( 45 1    !46 1     BITestModule1 ( ) (M) STATIC VIOLATION : 114 S : Expression isnot Boolean. 47 1    ) 48 2    { 49 2     if 50 2      ( 51 2      ! 522       BackupModule1 ( ) (M) STATIC VIOLATION : 114 S : Expression isnot Boolean. 53 2      ) 54 3      { (M) STATIC VIOLATION : No bracketsto then/else (added by analysis). 55 3       return 56 3       − 1 ; 574      } 58 5    } 59 6   if 60 6    ( 61 6    ! 62 6     BITestModule2( ) (M) STATIC VIOLATION : 114 S : Expression is not Boolean. 63 6    )67 7      ! 68 7       BackupModule2 ( ) (M) STATIC VIOLATION : 114 S :MISRA-C:2004 12.6 13.2: Expression is not Boolean. 69 7      )

Moreover, the static analysis tool 120 can be reapplied to instrumentand measure code coverage in tests run externally.

The unit/integration test tool 125 can be implemented to test the sourcecode against the requirements. In an embodiment, the unit/integrationtest tool 125 can run test cases defining inputs to portions of thesource code and expected outputs, and generate results that describecode coverage. For example, the source code can be implemented as aplurality of functions. If a particular function is called and executedduring unit/integration testing, then the function can be described asbeing “covered.” Thus, it is typically desirable to have a highpercentage of the source code covered. Also, different levels ofcoverage can be tested during unit/integration testing, such as pathcoverage, statement coverage, branch coverage, and modifiedcondition/decision coverage (MC/DC). Automation and integration testingsoftware products, such as LDRA TBrun™; Parasoft's (on the web atparasoft.com) C++ Test, C++ Test for Embedded Systems, Code Wizard andJest with Test Case Sniffer; Vector Software's (on the web atvectorcast.com) VectorCAST/Ada, VectorCAST/C, VectorCAST RSP forReal-time Embedded Testing and VectorCAST/Cover; IBM Rational(www-306.ibm.com/software/rational/) Test RealTime; IPL (on the web atipl.com) Adatest 95 and Cantata++; Free Software Foundation's (on theweb at gnu.org) Cunit, CPPunit and Junit; and Testwell (on the web attestwell.fi) CTA++, C++ Test Aider, CTC++, Test Coverage Analyzer forC/C++, can be employed to implement the unit/integration test tool 125.

For the on-line grocery store example, an exemplary test case might testthe procedures mapped to the requirement “maintain account,” such asfloat MaintainAccountFunction( ), against the requirement. In thisexample, the test case might specify that if theGetAccountBalance(accntNum) is called with an input value=3201, the testcase would return a value=1. The coverage results of unit testing inthis example might be represented as follows:

     --COVERAGE--    - Statement - Desired Coverage(%): 80 MappedProcedures Passing(%): 89 - Branch Decision - Desired Coverage(%): 60Mapped Procedures Passing(%): 63 - Path - Desired Coverage(%): 70 MappedProcedures Passing(%): 72

For the avionics display system example, an exemplary test case mighttest the procedures mapped to the requirement “Isolate faults,” such asint CheckAvionicsDisplay( ), against the requirement. In this example,the test case might specify that if the function BlTestModule3( ) is setto 1 and BackupModule3( ) returns 1. The coverage results of unittesting in this example might be represented as follows:

     --COVERAGE--    - Statement - Desired Coverage(%): 80 MappedProcedures Passing(%): 61 - Branch Decision - Desired Coverage(%): 60Mapped Procedures Passing(%): 51 - Path - Desired Coverage(%): 50 MappedProcedures Passing(%): 48

Tracing whether the captured requirements have been implemented insource code and verifying whether the implemented source code operatesas desired can be performed manually, but for large software developmentprojects having thousands of requirements, manual tracing andverification of the requirements can quickly become impractical andunmanageable. Accordingly, as shown in FIG. 1A, the automatedrequirements verification tool 115 can be implemented to bridge the gapbetween the requirements capture tool 110 and the static analysis andunit/integration test tools 120 and 125. FIG. 1B illustrates anexemplary implementation of the automated requirements verification tool115 that includes a requirements module 140, a projects module 145, amapping & analysis module 150, a verification module 155, and a networkinterface module 160. The LDRA TBmanager™ tool, described herein inconjunction with FIGS. 4A-4J, can be employed to implement the automatedrequirements verification tool 115.

The requirements module 140 can be configured to define requirements forthe software development project based on the requirements informationcaptured by the requirements capture tool 110 from the requirementsinformation source 105. The captured requirements information canrepresent customer-defined, project-level requirements for the softwaredevelopment project, which are referred to herein as “high-level”requirements. In the on-line grocery store example, the capturedrequirement “maintain account” is an exemplary high-level requirement.High-level requirements, however, do not describe code-level, designrequirements necessary for actually implementing the software. Thus, therequirements module 140 can be configured to provide the option ofdefining additional requirements not captured by the requirementscapture tool 110.

For example, the requirements module 140 can be used to definerequirements that fulfill part of a high-level requirement, referred toherein as “low-level” requirements. Low-level requirements can bedefined to specify how a portion of the software should be implemented.For example, a low-level requirement might focus on a specific function,aim or goal. In the on-line grocery store example, a low-levelrequirement called “account_name” can be defined for the high-levelrequirement “maintain account” to establish a name for the account. Inanother example, the avionics display system, the low-level requirement,“enable named redundant system” is defined for the high-levelrequirement “Isolate faults” to ensure that only the redundant moduleidentified by Built In Test is enabled.

The requirements module 140 can also be used to define requirements thatare inferred or derived from high-level requirements or low-levelrequirements, referred to herein as “derived” requirements. Thus,derived requirements may not be captured by the requirements capturetool 110 but can be subsequently created and managed by the automatedrequirements verification tool 115. In the on-line grocery storeexample, a derived requirement called “cancel_account” can be definedfor the high-level requirement “maintain account” to cancel a maintainedaccount. In another example, the avionics display system, a derivedrequirement called “damage assessment” can be defined for the high-levelrequirement “Isolate faults” to facilitate recovery procedurenotification.

The requirements module 140 can further be used to define requirementsthat are copies of a high-level, low-level or derived requirement,referred to herein as “sibling” requirements. A sibling requirement canbe created for the purposes of requirement diversification and taskmanagement (e.g., one of the users 135 might write source code toimplement a low-level requirement, while another one of the users 135might verify the implemented source code). As described herein, asibling requirement can be distinguished by a unique identifier,although it is otherwise identical to the base high-level, low-level, orderived requirement of which it is a copy. In this way, the requirementsmodule 140 can be used to populate the RTM with the captured high-levelrequirements from the requirements information source 105, as well aswith additional low-level, derived, and sibling requirements to enablethe automated requirements verification tool 115 to provide automatedrequirements traceability down to the source code level.

A sibling requirement can be called a verification task. An additionalsibling type, or verification task, is called an objective. Objectivesare defined to assure conformance with process objectives or qualitativeassessments such as requirement validation or proper planning anddocumentation.

Another sibling requirement type is associated with defect reportgeneration and resolution. A defect report, the obverse of arequirement, can be generated automatically by the users of the staticanalysis tool 120 or the unit/integration test tool 125. The assignmentof defect report spawns a sibling or verification task whose solepurpose is the tracking of defect report to closure.

The projects module 145 can be configured to establish a project. Asreferred to herein, a “project” established by the projects module 145describes an electronic realization of a real-world software developmentproject in that the established project can provide an electronicmechanism for organizing and automating many aspects of the real-worldproject, including, among other aspects, defining the requirements forthe project, assigning users to work on the project, tracing theimplementation of the requirements, analyzing and verifying source codefiles developed to implement the requirements, and tracking defects. Theestablished project can include associated requirements information andsource code files written by developers to implement the requirements.In one embodiment, source code previously developed for a requirementcan be associated with the project. If source code is not alreadydeveloped for the requirement, the projects module 145 can facilitaterequirements-based development in which assigning the requirement to auser is a precursor to source code development.

The projects module 145 can be configured to display a hierarchicalrepresentation of the associated requirements and source code files forthe established project and can provide information on the status of arequirement (e.g., whether the requirement is verified or unverified,the users assigned to work on the requirement, etc.). For example, FIG.4C, described herein in conjunction with an exemplary user interface,illustrates a Project Tree 412 for the on-line grocery store exampleshowing a hierarchy of requirements and source code files. By linkinghigh-level requirements with their low-level implementations, theprojects module 145 can enable project managers to view arequirement-by-requirement breakdown of which requirements'implementations have met coding convention, code coverage levels, andfunctional testing criteria. In this way, the projects module 145 canprovide an integrated requirements traceability and verification matrix.In an embodiment, the projects module 145 can generate a status reportsummarizing the requirements information for a particular user that canbe updated as the project progresses to include code coverage resultsafter unit testing, as described herein, among other information.

The projects module 145 can be configured to add the users 135 to theproject. The users 135 can include any persons working on the project,such as project managers, software developers, test engineers, etc. Inan embodiment, the projects module 145 can create “roles” for theproject based on groups of the users 135, who are designated to performsimilar actions, and to assign the created roles to the users 135. Forexample, a developer role, a test engineer role, an independentverification and validation (IVV) role, and a quality assurance (QA)role can be created, among others. In an embodiment, a project managerrole can be created so that a user assigned the role of project managercan exercise control over virtually all aspects of the requirementsverification process and can create other roles, as well as assign rolesand requirements to the users 135.

In an embodiment, permissions can be assigned to the roles to defineactions that users assigned to the role can perform. Exemplarypermissions include, among others, a create low-level requirementspermission, a create derived requirements permission, a makesub-projects permission (e.g., where a sub-project can be establishedwhen a requirement is assigned to a user, as described herein), an editthread properties permission (e.g., where an XML thread can be createdfor each requirement, as described herein), and a manual verificationpermission (e.g., to permit a user to access the verification module 155to review results of the unit testing, code coverage and static analysisas described herein).

The projects module 145 can also be configured to enable a user with thenecessary permissions to assign requirements (i.e., the high-level,low-level, derived, and sibling requirements) defined by therequirements module 140 to the users 135. In one embodiment, assignmentof a requirement to a user can establish a corresponding sub-project. A“sub-project,” as referred to herein, describes a workspace that theuser can access to perform designated tasks associated with theirassigned role (e.g., writing source code, analyzing source code files,testing source code files, etc.).

In one embodiment, the projects module 145 can regulate the operationalstatus of a sub-project to require that users “check-out” a sub-projectfrom the projects module 145 before performing any tasks on thesub-project and “check-in” the sub-project to the projects module 145upon completion of the task(s). That is, to check-out a sub-project,users can make a copy of their sub-project file for the purpose ofperforming tasks remotely (e.g., on their own computers) and, tocheck-in the sub-project, users can copy the modified contents of theirsub-project file back into a directory tree for the established project.In this way, the projects module 145 can maintain integrity of the RTMby synchronizing the sub-projects with the current state of the RTM eachtime the users check-in and check-out their sub-projects. Additionally,as described herein, a create sub-projects permission can be assigned toenable a user to update sub-projects via the projects module 145. Forexample, as described herein, affected sub-projects should be updatedwhen their corresponding requirements are modified (e.g., due to theaddition or deletion of a user).

The network interface module 160, shown in FIG. 1B, can be configured toenable global distribution of the project and provide integratedprocesses over the communications network 130 (e.g., a LAN, WAN, theInternet, etc.). In an embodiment, the network interface module 160 canenable the users 135 to check-in and check-out their sub-projects fromremote locations. Security measures can be implemented, such asestablishing a secure connection and requiring the users 135 to logonand supply a password. Additionally, verification status reports can bemade globally available. In these ways, the network interface module 160can be used to perform synchronous or asynchronous operations and toeffect a globally-based dynamically updated requirements matrix (bothtraceability and verification matrix).

The mapping & analysis module 150, shown in FIG. 1B, can be configuredto invoke the static analysis tool 120. As described herein, the mapping& analysis module 150 can invoke the static analysis tool 120 to mapprocedures identified in source code to the defined requirements for theproject. For the on-line grocery store example, the procedures floatMaintainAccountFunction( ), long GetSessionAccountNumber( ), floatGetAverageAccountBalance(long accntNum), float GetAccountBalance(longaccntNum) void FatalError(const char*msg), void UserMessage(constchar*msg) identified in the exemplary source code file“MaintainAccount.c” can be mapped to the high-level requirement“maintain account.” For the avionics display system example, theprocedures int CheckAvionicsDisplay( ); int BITestModule1( ); intBITestModule2( ); int BITestModule3( ); int BackupModule1( ); intBackupModule2( ); int BackupModule3( ). An exemplary graphical userinterface for mapping procedures to requirements is illustrated in FIG.4G, which is described herein.

Additionally, the mapping & analysis module 150 can enable a user toverify a requirement by identifying an analysis requirement verificationmethod and/or a test requirement verification method. For example, inone embodiment, the mapping & analysis module 150 can be used to invokethe static analysis tool 120 to provide integrated analysiscapabilities, including analyzing the mapped procedures against projectcoding rules and quality metrics. Additionally, in another embodiment,the mapping & analysis module 150 can be used to invoke theunit/integration test tool 125 to test the mapped procedures against therequirements, as described herein, by running test cases and generatingresults that describe code coverage. And in another embodiment, themapping & analysis module 150 can be used to instrument code that willbe executed externally and whose execution results (i.e., code coverageresults) can subsequently be returned to the mapping & analysis module150 for the purpose of post-mortem code coverage analysis.

The verification module 155, shown in FIG. 1B, can be configured toverify the defined requirements based on the results of analysesperformed on the mapped procedures by the static analysis tool 120, aswell as results of the unit testing performed on the mapped proceduresby the unit/integration test tool 125. For example, in one embodiment, auser with the necessary permission can use the verification module 155to select a requirement and view the expected code coverage and theachieved code coverage for the selected requirement (e.g., aspercentages of the mapped procedures achieving a desired coverage). Ifthe user is satisfied with the coverage achieved for the selectedrequirement, the user can maintain the current status of the selectedrequirement as verified. However, if the user is unsatisfied with thecoverage achieved for the selected requirement, the user can change thecurrent status of the selected requirement to unverified. Becauseun-verifying a requirement modifies that requirement thread, asdescribed herein with respect to the exemplary XML implementation, theuser should subsequently update any sub-projects associated with therequirement.

The verification module 155 can also be configured to create groupsunder a user, and associate requirements with respective groups. Groupshave verification rules assigned to them, such that when a requirementis assigned to a group, a sibling requirement for each verification ruleis generated for that (base) requirement. With respect to testverification rules, a sibling or verification task is created for eachtest case associated with the base requirement. All requirements can beungrouped requirements initially. Requirements can then be associatedwith one or more groups.

Verification rules specify what a verification task that must becompleted before the requirement can be considered verified in thisexemplary embodiments. What a requirement must satisfy is determined bythe verification group that the requirement is in. Verification rulesspecify not only what verification task must be done; they also specifywho should do them. A verification rule can specify that the requirementpass Code Review, and can further specify that Code Review be performedby a certain user or a user of a certain role (e.g., “Tester” or “QA”).Rules may be sequenced, which forces them to be performed in the orderlisted in the verification group.

When a verification rule is defined, one or more quality models can beapplied. A quality model can set a standard via which the quality ofsoftware for a given project can be measure and visualized. A qualitymodel is enforced by the code review and quality review verificationtasks.

The code review standards can be defined in a pair of files, a reportfile (<language>report.dat) and a penalty file (<language>pen.dat). Thereport file contains the complete set of predefined coding rules. Thisset of rules can be extended to accommodate a given project. Subsets ofthe rule set, as defined by published coding standards, are predefinedso the user may apply those standards without having intimate knowledgeof details of the standard. By viewing the report file, one can see themapping of these standards to rules and their enforcement. The penaltyfile can be a legacy mechanism for configuring the code review.

The quality review standards can be defined in ‘metpen.dat’. This filecontains a series of analysis measurements which are paired withtolerance thresholds. For instance, cyclomatic complexity measurements,code complexity measurements, unreachable lines measurements,comment-related ratios measurements. If the complexity exceeds a certainpreset threshold, the quality review report will flag it accordingly. Aswith the ‘report.dat’ file used for code review, the ‘metpen.dat’ filemay be customized to meet a project's needs.

The selection of different quality models can be achieved viacombinations of verification rules assigned to groups. When siblingrequirements are invoked for code or quality review, the appropriatequality model is applied for testing.

As mentioned above, a sibling (e.g. verification task) is generated forevery verification rule that the base requirement must satisfy. Forexample, if a requirement's verification rule stipulates that it passcode review, then a sibling is made, and if the sibling passes codereview, then the requirement is considered as passing code review.

Accordingly, the automated requirements verification tool 115 can beemployed in a software development project to enable automatedintegration of requirements-based development and verification processesand provide global access to a dynamically-updated traceability andverification requirements matrix to all members of a project team,including management. As described herein, in one embodiment, theautomated requirements verification tool 115 can be implemented usingthe extensible markup language (XML).

In order to automate and make a repeatable process of requirementstraceability, a triangulation of the test verification process must besupported. This triangulation includes three vectors: the mappedrequirement (a static association including a procedure, an aggregationof procedures, a class or any implementation artifact), the structuralcoverage (a dynamic metric of test case execution) and the test case(the functionality to be exercised). The realization of requirementtraceability is greatly complicated by software programming abstractionssuch as overloading, multiple inheritance, generic parameterizations anddynamic dispatch tables. The present invention achieves thistraceability by integrating its static and dynamic vectors as dictatedby the required functionality. The traceability facilitated by theinvention, including the use of the static analysis tool 120, isextended to instances of the software and its run time artifacts. Inaddition to the mapped requirement, the test case (or use case) must beexplicitly mapped as a predicate for any test-based verification task tobe performed.

Process Overview

FIG. 2 illustrates exemplary steps for a process 200 for electronicallymanaging requirements for software development. Not all of the steps ofFIG. 2 have to occur in the order shown, as will be apparent to personsskilled in the art based on the teachings herein. Other operational andstructural embodiments will be apparent to persons skilled in the artbased on the following discussion. These steps are described in detailbelow.

In step 205, a software development project is established. For example,the projects module 145, described in conjunction with FIG. 1B, can beemployed to implement step 205. In an embodiment, step 205 includesidentifying users for the project. In another embodiment, step 205includes creating a plurality of roles for the project based on groupsof the users who are designated to perform similar actions. For example,a project manager role can be created having permission to exercisecontrol over the process 200, and at least one additional role can becreated, such as a developer role, a test engineer role, an independentverification and validation role, and a quality assurance role. In thisembodiment, step 205 can include assigning permissions to the roles todefine the actions that the users can perform, such as a createlow-level requirements permission, a create derived requirementspermission, a make sub-projects permission, an edit thread propertiespermission, and a manual verification permission, and step 205 can alsoinclude selecting roles for the users.

In step 210, requirements for the project are defined based onrequirements information captured from a requirements source. Forexample, the requirements module 140, described in conjunction with FIG.1B, can be employed to implement step 210. In one embodiment, step 210includes capturing high-level requirements for the project based on therequirements information, and defining at least one additionalrequirement for the project based on the requirements information. Theadditional requirement(s) can define a low-level requirement thatfulfills part of a captured and allocated high-level requirement for theproject, a derived requirement that is inferred from a definedhigh-level requirement or low-level requirement for the project, and/ora sibling requirement that is a copy of a defined high-level, low-level,or derived requirement for the project. Additional requirementsinformation can include test cases associated with any givenrequirement. In the absence of test cases defined as part of theoriginal requirements information, the user must enter a test casebefore performing a test-based verification task.

In step 212, for each requirement, source code already developed for therequirement is associated with the project. For example, the projectsmodule 145, described in conjunction with FIG. 1B, can be employed toimplement step 212. Additionally, if source code is not alreadydeveloped for a requirement, step 212 can facilitate requirements-baseddevelopment in which requirements assignment is a precursor to sourcecode implementation. In this embodiment, the association of source codewith a project does not occur until step 215. In step 212, correspondingsub-projects can be established when assigning the defined requirementsfor the project to the users.

Optionally, the process 200 can include the additional steps ofgenerating a status report for a user summarizing the definedrequirements assigned to the user, and updating the status report duringthe project to include corresponding results of the analyses, codecoverage and the unit testing.

In step 215, procedures identified in the source code are mapped to thedefined requirements for the project. For example, the mapping &analysis module 150, described in conjunction with FIG. 1B, can beemployed to implement step 215. In one embodiment, step 215 includesinvoking a static analysis tool, such as the static analysis tool 120described in conjunction with FIG. 1A, to analyze the source code toidentify the procedures in the source code. In this embodiment, thestatic analysis tool can also be invoked to perform analyses on thesource code, including applying project coding rules and quality metricsto the associated source code files. Moreover, this static analysis tool120 can be used to instrument and measure code coverage in tests runexternally. In another embodiment, step 215 includes invoking a unittest tool, such as the unit/integration test tool 125 described inconjunction with FIG. 1A, to run test cases on the mapped procedures.

In step 220, the defined requirements for the project are verified basedon results of one or more of analyses, code coverage measurements andunit testing performed on the mapped procedures. For example, theverification module 155, described in conjunction with FIG. 1B, can beemployed to implement step 220. In one embodiment, step 220 includesverifying the defined requirements for the project if results of theanalyses indicate conformance of the source code to the project codingrules and the quality metrics. In this embodiment, the non-conformancescan be tracked based on the results of the analyses, and thenon-conformances, including providing information regarding dispositionof the non-conformances, can be reported. In another embodiment, step220 includes verifying the defined requirements for the project if thetest cases generate desired results.

In yet another embodiment, step 220 includes the additional steps ofproviding a status of the defined requirements for the projectindicating whether each of the defined requirements is verified orunverified, and generating an integrated requirements traceability andverification matrix to dynamically track implementation of the definedrequirements and the status of the defined requirements. In thisembodiment, sub-projects for the project can be established by assigningthe defined requirements for the project to users working on theproject, and the sub-projects can be synchronized with the integratedrequirements traceability and verification matrix.

Optionally, the process 200 further includes the step of enabling theusers to access the project via a communications network. For example,the network interface module 160, described in conjunction with FIG. 1B,can be employed to implement the networking step. In an embodiment, theintegrity of the requirements traceability and verification matrix canbe maintained by monitoring when the users check-out and check-in theircorresponding sub-projects over the communications network. In otherwords, the process 200 can support a unit test workflow scenario thatincludes requirements traceability and test verification throughhigh-level, low-level and derived requirements and facilitates themapping of these requirements with source code procedures or methods.The mapped requirements can subsequently be made available to adeveloper or a tester for the purposes of test specification creationand test verification. The process 200 can also facilitate the creationof test cases from these test specifications. The process 200 canautomatically trace the results of this unit test scenario back to therequirements sources to ensure requirements traceability matrix (RTM)integrity and user workspace (e.g., project/subproject) security andflexibility in its deployment. In an embodiment, a user can operate on a“checked-in” sub-project, where all tasks performed by the user can bedynamically tracked and updates to the RTM can be synchronized, or theuser can operate on a “checked-out” sub-project, where verificationtasks can be performed at any location and results can be subsequentlysynchronized with the current RTM when the user returns to operate on achecked-in sub-project.

Detailed Description of Exemplary XML Implementation

As described herein, the automated requirements verification tool 115and the automated requirements management process 200 can be employed ina software development project to bridge the gap between high-levelrequirement traceability tools and low-level code testing tools and, inone embodiment, can be implemented using XML constructs.

For example, requirements management data can persist in an XMLconstruct called a “thread,” so that each requirement that is trackedhas one corresponding XML thread. In this way, as referred to herein,the terms “thread” and “requirement” can essentially be interchangeable,except a thread more accurately describes a requirement-based task andmore. For example, as shown in FIG. 3A, a thread 305 can includemetadata describing the requirement and its relationship to otherrequirements 310, as well as prototype information regarding proceduresin source code files that are mapped to the requirement 315 and analysisand test result information 320 pertaining to verification of therequirement. All prototype information can be kept in the thread itself,including the code coverage information using a <Prototype></Prototype>XML block.

With the exception of hierarchical information (i.e., threadrelationship data can be contained in the threads themselves, but allthe threads taken together form a cohesive hierarchy), all pertinentinformation about a thread can be contained in the thread itself. Inthis way, a thread can largely be a self-contained object, enabling aprogram to use thread information sensibly without any knowledge of theproject the thread belongs to, including user, role, and permissioninformation. For example, FIG. 3C illustrates a project schematic 340and shows that a thread XML file 345 can be independent from project XMLfiles 350, 355 and 360 that can be used to create a cohesive project andto present the thread information to the users in a useful and intuitivemanner.

The thread definition itself can specify a minimum number andarrangement of fields (also called “elements” when speaking within anXML specific context), which must exist for the data aggregation to becalled a “thread” proper. Whether the information put into those fieldshas any correlation with real-world data is beyond the scope of thethread definition. The definition of a thread is dependent only upon aunique reference identifier (e.g., ref=“ ” metadata) and not upon theactual string used to make the threads human-readable.

FIG. 3B illustrates how a thread XML file 335 can be manipulated by acalling application/program 325 through an XML wrapper class calledCXMLWrapper. While it can be possible to read and write directly from/tothreads, the CXMLWrapper can be used to enforce the ref=“ ” XMLconventions, thereby ensuring that threads are written and re-written ina consistent, standards-conforming manner.

FIG. 3D illustrates an exemplary representation of a thread in memory.The CXMLWrapper class is based on the CGenericXMLWrapper XML wrapperclass, which can be implemented to convert an XML file into ahierarchical tree of objects called ReqDataContainers 365. Conceptually,a ReqDataContainer 365 can maintain hierarchical information aboutitself (e.g., who its parents and children are) and about its own data(e.g., name, unique reference identifier, and data). TheCGenericXMLWrapper class can create one ReqDataContainer for eachelement encountered while reading an XML file. The element's name andunique reference number can be stored, in addition to any data.Hierarchical information can be contextually determined based onrelevant factors such as, whether the element has data and the parentelement, among other factors. Thus, in the tree of ReqDataContainers,each ReqDataContainer can be analogous to a node with pointers to itssiblings in the tree.

In the event an element is encountered that does not have a referencenumber, a reference number can be assigned to the element, beginning ata reasonably high “unknown floor.” Thus, a program wishing to retrievethe element's data must know the value of the unknown floor ahead oftime, which can be defined in the XMLWrapper.h class, in addition toother factors regarding how many unreferenced elements are being readand have been read. In practice, it can be more effective to define athread tree by using a unique reference number (or other uniqueidentifier) for each of the elements of a thread instead of relying onautomatic assignment of reference numbers. Automatic assignment ofreference numbers can be effective, however, to prevent a situationwhere an entire thread (or _trace.xml file) cannot be accessed because afaulty portion of a program did not assign a reference number to one ofits new elements.

Once the CGenericXMLWrapper class creates a ReqDataContainer tree, asshown in FIG. 3D, a calling program can have complete freedom to modifythe ReqDataContainer tree. For example, a calling program can add orremove ReqDataContainers and modify data in existing ReqDataContainers.After a calling program has finished modifying a ReqDataContainer tree,it can call an XML method of the wrapper class called WriteAsXML( ) tohave the wrapper class convert the ReqDataContainer tree back into anXML file and write the XML file to a storage device.

ReqDataContainers 365 can be designed to mimic XML as much as possible.ReqDataContainers need not be categorized based on whether they havedata, children, siblings, or any other contextual property. In practice,however, some distinctions among the ReqDataContainers should beimplemented so that the data can be organized accordingly.

The flexible nature of a ReqDataContainer tree implementation can permitdifferent programs to add their own data to the thread withoutinterfering with each other. For example, in one embodiment, defecttracking information and function prototype XML blocks can be added to athread's “scope” without obfuscating its primary payload, the individualrequirement. These are examples of data that is added to threads asindividual traceability needs arise (in this case, the extension ofverification down to individual functions), and in this way, theapproach of encapsulating all data related to the requirement and itstraceability information into a single thread can enable flexibility andfreedom for user programs. The ReqDataContainer tree implementation canalso define a standard way of encoding data. In this way, programs whichwant to take advantage of features offered by other programs need onlyunderstand the XML block convention used in order to build their ownfunctionality around it.

In one embodiment, classes called RDCPtr, iRDCPtr, and CWrapperLibrary,can be implemented to (1) organize iterated XML blocks into “stacks” of“vertical data” to avoid the need for contact with a parent node, (2)enable sequential accessing of siblings without the need forcommunicating with the parent node, and (3) provide a one-to-onecorrelation between a ReqDataContainer and a single element of a storedXML file.

Avoiding reliance upon parent nodes for information about childhierarchical relationships can improve the integrity of the code. Forexample, programs typically need access to all instances of a certainXML block, such as getting prototype information out of a thread. Apseudocode representation of a function which gets prototype informationfrom a thread without using the RDCPtr class can be expressed asfollows:

ReqDataContainer prototype_parent =     current_thread.GetElement(REF_TEST_SPECIFICATION);   ReqDataContainer prototype =     prototype_parent.GetElement(REF_PROTOTYPE);    while (prototype !=NULL) {      PrintPrototypeInfo(prototype);      prototype =prototype_parent.NextElement(prototype);    }A pseudocode representation of a function which gets prototypeinformation from a thread using the RDCPtr class can be expressed asfollows:

  RDCPtr prototype = current_thread      .GetElement(REF_TEST_SPECIFICATION)      .GetElement(REF_PROTOTYPE);    while (prototype != NULL) {      PrintPrototypeInfo(prototype);       prototype =prototype.GetNext( );    }

The improvement with regard to code cleanliness between the twoimplementations can be significant considering that this “list” ofprototypes that a thread possesses can be passed around, in itsentirety, by passing only the RDCPtr of the first prototype because thefirst prototype in the list knows the location of the other prototypes.Thus, instead of a function passing around two ReqDataContainer pointers(i.e., one for the element and one for its parent), only one RDCPtrobject need be passed around for every function to have access to allthe prototypes. Further, the wrapper class only has to service oneapplication call (i.e., the call which gets the first prototype) andwill not need to service other calls to get any additional prototypeinformation. In this way, iterated blocks of XML data can be representedas “vertical” data, as shown in FIGS. 3D and 3E. The first prototype canbe treated like any other block of XML, and subsequently read prototypeblocks can be “stacked” on top of the first prototype. The RDCPtr classembodies this concept of stacks of ReqDataContainers.

Thus, the calling program need not interact with a ReqDataContainerdirectly. All data access can be accomplished via RDCPtrs, which canenable the unique “vertical data” stacking mechanism shown in FIGS. 3Dand 3E. Because of their usefulness as smart pointers, RDCPtrs canprovide exclusive means of accessing ReqDataContainers. Even if anelement has no vertical data (i.e., there is only one iteration of theelement), it can still be returned as an RDCPtr. Thus, functions do notneed to be overwritten to accept both ReqDataContainers and RDCPtrs, allfunctions can simply accept an RDCPtr. By passing around one relativelysmall RDCPtr, the entire calling program can have random or sequentialaccess to the entire vertical stack of data. This feature can enableeasier, cleaner, and more concise code implementation. Furthermore, byusing RDCPtrs, the calling program need not create or deleteReqDataContainers into or from memory, which can be all handledautomatically, as described herein.

The iRDCPtr class can provide a mechanism for organizingReqDataContainers “left and right” into lists. The iRDCPtr class is notused by calling programs but can be used by the backend (e.g., thewrappers used to interface with the XML files) to enable sequentialsearching through siblings and writing recursive algorithms to searchthrough the ReqDataContainer tree (ReqDataContainers do not keep trackof their “siblings” in the ReqDataContainer tree). Calling programs canaccess a child of a ReqDataContainers by index (i.e., by uniquereference identifier) and cannot sequentially search through thechildren of a ReqDataContainer to find the child it needs but, forinternal processes, the CGenericXMLWrapper can use iRDCPtrs tosequentially search through the children of a ReqDataContainer.

Calling programs should use CWrapperLibrary class to get a wrapper foran XML file. For memory management purposes, the automated requirementsverification tool 115 and its backend can use a class to manageallocation and deletion of resources. For example, the CXMLWrapper classcan be used to create the ReqDataContainers, RDCPtrs, and iRDCPtrsneeded. A calling program can obtain RDCPtrs upon request, and theentire XML file, as represented by the CXMLWrapper, can be created anddeleted with the CXMLWrapper. The CXMLWrapper, in turn, can register allobjects (e.g., ReqDataContainers) it creates with a GlobalRDCPoolobject, which can be emptied by the calling program when it exits.

Further, the automated requirements verificaiton tool 115 and itsbackend can use a class called CWrapperLibrary to manage CXMLWrappers inthe same way that the GlobalRDCPool class manages RDCPtrs. WithCWrapperLibrary, a calling program need not create a wrapper at all.Rather, the calling program can request the ReqDataContainer tree for anXML file. If the ReqDataContainer tree has not yet been built for therequested XML file, the CWrapperLibrary class can be used to create awrapper, have the wrapper build the ReqDataContainer tree, and pass backto the calling program a pointer to the created wrapper. In this way,CWrapperLibrary can organize all the CGenericXMLWrappers that a callingprogram is using. For example, if the calling program requests a wrapperthat corresponds to “file1_trace.xml,” CXMLWrapper can search a libraryof already-built wrappers for a CXMLWrapper object for file1_trace.xml.If a CXMLWrapper object for file1_trace.xml has already been built,CXMLWrapper can simply pass a pointer to the already-built CXMLWrapperback to the calling program, otherwise CWrapperLibrary can make a newCXMLWrapper for file1_trace.xml and pass a pointer to the new objectback to the calling program.

Like RDCPtrs, CXMLWrapper hides allocation of memory from the callingprogram, so the calling program is not responsible for freeing theobject that CWrapperLibrary passes back. Also, when a calling programuses CWrapperLibrary, all parts of the program can be certain to beworking on the same ReqDataContainer tree (a ReqDataContainer is asingle element in an XML file, so a tree of ReqDataContainers representsthe entire XML file) and the calling program does not have to implementsynchronization across the program.

Typically, a calling program will call the GetFile( )method to retrievethe RDCPtr for the file's root element and will not make any furthercalls to the wrapper. The calling program does not delete the createdwrapper. Instead, the EmptyWrappers( )method (which also writes allopened wrappers to a storage device) can be used to delete wrappersvicariously. In this way, the CWrapperLibrary class can be used toensure that all parts of the automated requirements management programare working on the same ReqDataContainer tree and to facilitate memorymanagement.

The memory management classes, when used together, can result in anunbroken persistence of RDCPtrs (i.e., the RDCPtr a calling programreceives at the beginning of a session is the same RDCPtr the callingprogram would receive later in the session) to enable parts of thecalling program, which use the same GlobalRDCPool and CWrapperLibrary,to pass RDCPtrs around. Therefore, when the calling program decides toask the memory management classes to empty themselves can be animportant decision. For reasons of memory usage, under certainsituations, it may even be desirable to force-empty wrappers andRDCPtrs. This memory management technique can result in an increase inmemory usage for the program's lifecycle. Once memory usage reaches acertain level, it is unlikely to increase further, but for programs thatmight in their lifecycles incur the opening of dozens or even hundredsof XML files, force-emptying the memory management classes can bebeneficial. Care should be taken, however, that references to resourcesmanaged by the memory management classes are no longer needed afteremptying them.

In one embodiment, the threads can be converted into a SQL format forstorage and access over a global network. This process can be supportedby a web service that accepts upload requests from the automatedrequirements verification tool 115. This same web service can generatetraceability and verification reports upon request from web users.Additionally this web service can accommodate download requests to theautomated requirements verification tool 115. As a consequence of theseweb services, global project synchronization can be facilitated.

Exemplary Graphical User Interface Implementation

FIGS. 4A-4J illustrate an exemplary implementation of a graphical userinterface (GUI) for a software requirements management tool TBmanager™developed by LDRA™ TBmanager™ can be employed to facilitate managementand allocation of software requirements for development, testing andverification purposes. Persons skilled in the art will understand thatthe GUI design need not be limited to the design illustrated in FIGS.4A-4J and that other GUI designs can be implemented. In this embodiment,a project file (e.g., having a “.tbp” extension) can first be createdusing a requirements capture tool, such as TBreq™, developed byGeensys™, which can capture requirements information for a softwaredevelopment project from sources of requirements information such asTelelogic DOORS® or IBM Rational RequisitePro®, MS Excel®, MS Word®,among other sources of requirements information.

Defining Roles and Users

FIG. 4A illustrates an exemplary GUI 401 for defining roles for theproject during an initial set-up. Roles can be used to group togetherusers who perform similar or related tasks; for example, a role can becreated and applied to all of the developers of a project. Each user canbe assigned one role. One user can assume the role of project manager.The project manager role can exercise control over every aspect of therequirements management process and can be responsible for creatingroles and users and for delegating requirements. For example, theproject manager can create and assign a role to grant other users theability to create roles and users and to delegate requirements.

As shown in FIG. 4A, a New Role field 402 of GUI 401 can be used toenter the name of a new role, and the new role can be added by pressingthe Add button. Exemplary roles 403 can include a developer role, a GUIdesigner role, an independent verification and validation (IVV) role, aquality assurance (QA) role, and a test engineer role, among others. Asshown in FIG. 4A, the Remove Selected button can be used to remove anadded role, and the Import Roles From File button can be selected toimport roles that have been defined in a text file or in anotherproject.

Permissions can be assigned to the roles to enable different levels offunctionality for corresponding users, such as by defining therequirements information that the users can access and the actions thatthey can perform. As shown in FIG. 4A, the Assign Permissions button canbe used to assign permissions to the roles 403. Exemplary permissions404 can include, among others, “Create Low Level (LL) Reqs,” which canbe assigned to a role to enable corresponding users to create low-levelrequirements, “Create Derived (DV) Reqs,” which can be assigned to arole to enable corresponding users to create derived requirements, “MakeSubProjects,” which can enable corresponding users to assign users torequirements for the project, “Edit Thread Properties,” which can beassigned to a role to enable corresponding users to edit availablerequirement attributes via a Requirements View described herein, and“Manual Verification,” which can be assigned to a role to enablecorresponding users to access to a Verification View described herein.

Roles can be used to diversify allocated requirements among users. Inthis way, the same requirement (via sibling requirements) can beassigned to two or more users of differing roles, while maintainingtraceability of development and verification tasks. For example, thesame requirement can be assigned to a developer for coding, QA fortesting and IVV for independent validation and verification.

Similarly, FIG. 4B illustrates an exemplary GUI 405 for defining usersfor the project. As shown in FIG. 4B, a New User field 406 can be usedto enter the name of the new user and to select a corresponding role forthe new user, and the new user can be added by pressing the Add button.The added users can be displayed in a Users field 407. A Remove Selectedbutton can be used to remove an added user from the project, and anImport Roles From File button can be selected to import users previouslydefined in another file.

Adding news users and roles after setup can be performed safely, whenfollowed by a sub-project update, as described herein. However, oncerequirements have been assigned to users, as described herein, users androles should not be deleted. For example, deleting a role can result ina user losing necessary permission to work on the project and deleting auser can result in a requirement being unassigned. Accordingly, careshould be taken when deleting roles and users.

Parsing Based on Types View

Requirement documents can be imported and parsed. The parsing can beperformed based on types. A parsing schema must be described in a Typesfile. As illustrated in FIG. 7, many types files can be predefined,covering commonly used tools such as diagramming software, e.g., Visio702; requirement management tools, e.g., DOORS 704 and 706, and RationalRequisite Pro 708; word processing programs, e.g., MS Word 710;spreadsheet programs, e.g., Excel 712, and authoring and publishingsoftware, e.g., Framemaker 714. The types file can be a converter sothat it can understood how requirements are described in the referencedocument.

FIG. 8 illustrates an example of requirements in an MS Word file. Asillustrated in FIG. 8, appropriate styles must be applied to therequirement ID 802 and requirement text 804 so that the document can beparsed as the author intends.

FIGS. 9 and 10 illustrate examples of a type editor. The MS Word styleused in the document, including the requirement ID 802 and requirementtext 804, must be described in the type editor fields 902 and 1002, sothat the MS Word file can be parsed correctly.

Groups View

Verification Groups for a project can be created under a user. FIG. 5illustrates an example of selecting, creating, renaming or deleting agroup view in a “Verification Groups” dialog 500. Referring to FIG. 5, averification group is created by clicking the “New Group” button 502. Adialog box “Enter Group Information” 518 appears when the “New Group”button 502 is clicked. The name of the verification group can be enteredin the name text field 514. In this example, the group name “HighPriority” is entered in the name text field 514. In addition,description “Must be implemented in the current spiral” is entered inthe description text field 516. When the “OK” button 520 is clicked, averification group is created.

Once a Verification Group is created, a user can highlight the group andclick on the “Rules >” button 508 to edit verification rule(s) for agiven group. FIG. 6 illustrates an example of editing rules for a givengroup in an “Edit Rules” dialog 600. Referring to FIG. 6, when the “New”button 610 is clicked, a “New Rule” dialog 616 appears. In the “NewRule” dialog, the rules specify that the requirement must satisfy “UnitTesting” and must be completed by “The Requirement's Assignee” in textfields 602 and 604. The verification rules available for selection caninclude: Code Review, Quality Review, System Test, Unit Testing,Sub-System Test and Integration Test. It can also be decided whether theuser assigned to the requirement is allowed to execute the test, or ifanother user must execute the test. When the “OK” button 606 is clicked,the new rules are created under the “High Priority” group. The “<Group”608 button can be used to return to the “Verification Groups” dialog500. The “Save and Use” button 612 can be used to save the rules forfuture use. The “Use Existing” button 614 can be used to select savedrules for a given group.

Referring back to FIG. 5, the “Rename Group” button 504 can be used torename the group, once created. The “Delete Group” button 506 can beused to delete a group. The “Save and Use” button 510 can be used tosave the group information setting for future use. The “Use Existing”button 512 can be used to select saved group information setting for agiven group.

With a group being defined as described above, requirements can beassociated with the group. FIG. 11 illustrates an example of ungroupedrequirements and grouped requirements. In FIG. 11, REQ 1 1102 and REQ 21104 are ungrouped requirements. REQ 3 1106 and REQ 4 1108 are includedunder the group named “Static Testing.”

Sibling Requirement View

FIG. 12 illustrates an example of a sibling requirement view. In FIG.12, two sibling requirements 1202 and 1204 correspond with therequirement 1206. Sibling requirement 1202 is for code review, siblingrequirement 1204 is for quality review.

Verification can be driving by the set of sibling requirements, and eachrequires an individual test run to be executed. A requirement isverified only when all sibling requirement corresponding to therequirement have been verified.

FIG. 13 illustrates another example of a sibling requirement view. InFIG. 13, sibling requirement 1306 is under the group named “StaticTesting” 1304 associated with a developer, named “Sam Brown” 1302. Thesibling requirement 1306 indicates that the verification task is codereview. In this example, the verification status 1308 of the siblingrequirement 1306 is “Passed.” It is also indicated that source filesnamed CashRegister.cpp and Backbeat.cpp 1310 and 1312 are associatedwith the sibling requirement 1306.

Project View

As shown in FIG. 4C, the GUI can have a tabbed format to provide userswith different views (e.g., Project, Verification, Define Requirement,Requirement Information, Assign Users, Map Procedures, and Procedures)that can be selected and actions that can be performed based on theirassigned roles. FIG. 4C illustrates a GUI 408 that can be displayed whenthe Project View tab is selected. The project GUI 408 can display allthe requirements assigned to and by the user (e.g., requirements in boldtype can represent those assigned to the user and requirements not inbold type can represent those that the user has assigned).

The project GUI 408 includes a Current Requirement drop-down menu 409,which can be used to select and display a particular requirement for theproject. The GUI 408 also includes buttons, such as an Open Projectbutton 410 a, which can be used to select a project or subproject filefor loading, an Update Sub-Projects button 410 b, which can be selectedto update/synchronize all currently checked-in sub-projects with recentmodifications to the requirements for the project, a Status Reportbutton 410 c, which can be selected to display a status report based onthe current requirements for the project, an Add Source button 410 d,which can be selected to add/upload a source file of code to the currentproject, a Remove Source button 410 e, which can be selected to remove acurrently selected source code file from the current project, a UnitTest button 410 f, which can be selected to launch an external tool forunit testing (e.g., LDRA Testbed™ and TBrun™), and a Setup Wizard button410 f, which can be selected to setup roles and users, if the currentuser has the necessary permission, as described herein. Additionalelements of the project GUI 408 include a User Guide button 411, whichcan be selected to display a user guide, as well as Exit and Savebuttons 413 and 414, which can be selected to exit the tool and save thecurrent project, respectively.

The project GUI 408 can also display a Project Tree 412 to show therequirements that are assigned to the user and any source code filesadded to the project. The Project Tree 412 can display each requirementby number, name, reference identifier and type, where different iconscan be used to represent different types of requirements. Additionally,an “X” symbol can be used over a requirements icon to indicate that thecorresponding requirement is unverified. To view more information abouta particular requirement, the user can select the RequirementInformation tab, as described herein.

Updating sub-projects can be performed to distribute modifications torequirements of the project to affected sub-projects. To updatesub-projects, users should first check-in their sub-projects. Then,after modifying the requirement (e.g., re-assigning the requirement,un-verifying the requirement, etc.), the Update Sub-Projects button 410b can be selected to disseminate the modification to all of the affectedchecked-in sub-projects so that when the users subsequently check-outtheir sub-projects, they can access the modification. While only usersworking on sub-projects affected by the requirements modification needcheck-in their sub-projects before updating sub-projects, all usersshould check-in their sub-projects to make a modification to users(e.g., when adding or removing users to/from the project).

In one embodiment, a user can generate a status report to display thecurrent status of all requirements associated with the user by selectingthe Status Report button 410 c. The status report can provide a summaryof the requirements assigned to or by the user and can display detailedrequirement attributes such as, requirement name, requirement number,requirement document, requirement body, user assigned to therequirement, and the role of the assigned user. As the projectprogresses and procedures are mapped to the requirements, as describedherein, the status report can be updated to include a table of mappedprocedures for each requirement. The table can display detailedattributes of the mapped procedures, such as the procedure name, thename and location of the source code file, the path coverage achieved,the branch decision coverage achieved, the MC/DC coverage achieved, andthe statement coverage achieved. The achieved coverage fields in thetable can remain empty until unit testing of the mapped procedure hasbeen performed, as described herein. After unit testing is performed,these fields can be updated to show the coverage achieved. Additionally,after unit testing is performed, the status report can indicate apercentage of the tested mapped procedures achieving the desiredcoverage. The status report can also be configured to distinguish howverified and unverified requirements are displayed, for example, byusing different color text.

After requirements have been defined and users have been assigned to thedefined requirements, as described herein, source code that has beendeveloped by the users can be added to the project by selecting the AddSource button 410 d. Once added, the source code can be displayed in theProject Tree 412. Note that source code files can be added to theproject but not to the requirements themselves because procedures in thesource code files, not the source code files themselves, can be mappedto the requirements, as described herein. Source code files can also beremoved from the project by selecting the source code file to be removedin the Project Tree 412 and pressing the Remove Source button 410 e.

Requirement Information View

FIG. 4D illustrates a GUI 415 that can be displayed when the RequirementInformation tab is selected. The requirement information GUI 415 candisplay information about the current selected requirement. Inparticular, the requirement information GUI 415 can group theinformation about the currently selected requirement into three areas ofinterest: test configuration, test management and requirementnomenclature. A Test Configuration drop-down menu 416 can be used toview and edit information about the test configuration properties of thecurrently selected requirement, a Test Management drop-down menu 418 canbe used to view and edit information about the test managementproperties of the currently selected requirement, and a RequirementNomenclature drop-down menu 417 can be used to view and edit informationabout the requirement nomenclature of the currently selectedrequirement. The requirement information GUI 415 includes a View/Editarea 419, in which the selected requirement can be displayed and/oredited. The View/Edit area 419 can be grayed out to indicate when theuser is not permitted to edit the value or description associated withthe selected requirement information.

Define Requirement View

During the life span of a project, there can be a need to introduce newrequirements or refine existing requirements. To define a requirement,the Define Requirement tab can be selected. FIG. 4E illustrates a GUI420 that can be displayed when the Define Requirement tab is selected.Using the define requirement GUI 420, the user can create and addlow-level or derived requirements to the project, depending on thepermissions assigned to the user's corresponding role. As describedherein, high-level requirements include requirements captured by therequirement capture tool and imported into the project. Low-levelrequirements include requirements that are associated with a high-levelrequirement. Derived requirements include requirements not captured bythe requirements capture tool but defined in TBmanager™ and are inferredor derived from high-level or low-level requirements.

As shown in FIG. 4E, the define requirement GUI 420 includes aRequirement Name field 421 that can be used to enter the name of therequirement being defined, Requirement Type radio buttons 422 that canbe used to select whether the requirement being defined is a derived(DV) or low-level (LL) requirement, and a Reference Requirementdrop-down menu 423 that can be used when defining low-level requirementsto select the high-level requirement with which the low-levelrequirement is associated (otherwise “None (DV Requirement)” can beselected). The define requirement GUI 420 also includes a RequirementNumber field 424 that can be used to enter the number of the requirementbeing defined. In one embodiment, each requirement for the projectrequires a unique identification number, which can be automaticallyfilled in by TBmanager™. The define requirement GUI 420 further includesa Requirement Document Path field 425 that can be used to enter the pathto a document detailing the requirement being defined (the Browse buttoncan be used to locate the document), a Requirement Body field 426 thatcan be used to enter a brief description of the requirement beingdefined, a Clear button 427 that can be used to clear all fields in thedefine requirement GUI 420, and a Create LL/DV Requirement button 428that can be pressed to create the new requirement. In one embodiment,TBmanager™ can automatically use values specified in a template whenimporting requirements into the project as values for the desired codecoverage for the new requirement. Newly defined low-level or derivedrequirements can be displayed in the Project Tree 412.

During the life span of a project, it might be necessary to dismiss orignore a requirement so that it will no longer be considered forverification purposes. A user can select a requirement to bede-allocated in the Project Tree 412 via the project GUI 408 and cande-allocate the selected requirement using a De-allocate/Re-allocateCurrent Requirement button 429 via the define requirement GUI 420. TheDe-allocate/Re-allocate Current Requirement button 429 can be configuredas a context-sensitive button with respect to the selected requirementso that it toggles between “De-Allocate Current Requirement” and“Re-allocate Current Requirement” as appropriate. Thus, a user canre-allocate a de-allocated requirement in a similar manner by selectingthe de-allocated requirement in the Project Tree 412 via the project GUI408 and can re-allocate the selected requirement using theDe-allocate/Re-allocate Current Requirement button 429 via the definerequirement GUI 420.

Assign Users View

Having setup the roles and users of the project, users can be assignedrequirements to work on by selecting the Assign Users tab. FIG. 4Fillustrates a GUI 430 that can be displayed when the Assign Users tab isselected. Using the assign users GUI 430, a user having the necessarypermission can assign users to requirements and create siblingrequirements. As described herein, a sibling requirement can be createdin TBmanager™ for the purposes of requirement diversification and taskmanagement and represents a copy of a high-level, low-level or derivedrequirement for the project. A requirement that is to be assigned can beselected from the Project Tree 412 via the project GUI 408 or from aCurrent Requirement drop-down menu via the assign users GUI 430.

The assign users GUI 430 includes an “Assigned to this Requirement”field having a User field 431 that can display a name of a user assignedto the current requirement and a Role field 432 that can display therole assigned to the user. The assign users GUI 430 also includes an“Assign User” field having a Filter by Role drop-down menu 433 that canbe used to identify the users 435 for the project who are available forselection based on their corresponding role 434. An Assign toRequirement button 436 can be selected to assign a selected user fromthe identified users 435 to the current requirement.

To finish the assignment and create a sub-project for the user, the Savebutton 414 can be selected via the project GUI 408, followed by theUpdate Sub-Projects button 410 b. In one embodiment, a directory named“Sub-Projects” can be established in the project directory to containall of the users' sub-projects. Each user can have a separatesub-projects directory that can be automatically created when firstassigned a requirement. Users can then open their respectivesub-projects to work on assigned requirements. The users can copy theirsub-project directories to different machines (e.g., their ownworkstations or laptops with TBmanager™ installed) to work on assignedrequirements. Users can then launch TBmanager™ on their machines, selectthe Open Project button 410 a via the project GUI 408, navigate to theirsub-project directory, and select the appropriate sub-project to workon. Users can be asked to login by entering their name. The project GUI408 can then refresh itself to display the user's project and theassigned requirements.

The assign users GUI 430 can also be used to create a siblingrequirement, which is a copy of an existing high-level, low-level orderived requirement. The sibling requirement can be identical to thecorresponding high-level, low-level or derived base requirement exceptfor a unique identifier assigned to the sibling requirement. A siblingrequirement can duplicate a base requirement thread at the time thesibling requirement is created. In this way, sibling requirements canenable a user to assign the same requirement to multiple users havingdifferent roles (a sibling cannot be assigned to two users of the samerole).

To create a sibling requirement, one of the users 435 displayed via theassign users GUI 430 can be selected and assigned to the siblingrequirement by selecting a Create Sibling Req+Assign button 437. In oneembodiment, the user assigned to the sibling requirement should have adifferent role than the user assigned to the base requirement. A newlycreated sibling requirement can be viewed via the project GUI 408 anddisplayed in the Project Tree 412 as a child of the base requirement.Only users with permission to Make Sub-Projects should be enabled tocreate sibling requirements.

Because sibling requirements can be considered exact copies of acorresponding base requirement, if the base requirement changes, thenall of its associated sibling requirements should be de-allocated, asdescribed herein. Then, new sibling requirements of the modified baserequirement can be created and assigned to the appropriate users. If thebase requirement has a new procedure assigned to it, has its requirementbody changed, or any other change happens that might affect theconditions under which the base requirement can be verified, new siblingrequirements should to be created.

Map Procedures View

FIG. 4G illustrates a GUI 438 that can be displayed when the MapProcedures tab is selected. Having added source code files developed bythe users to the project, as described herein, the map procedures GUI438 can be used to select an added source code file, analyze theselected source code file for available procedures, and map selectedprocedures to a current selected requirement. The Project Source Filesdrop-down menu 439 can be used to select a source code file that hasbeen added to the current project and return a list of procedures 442found in the selected source code file. For example, the LDRA Testbed™tool can be invoked to analyze the selected source code file and returnthe identified list of procedures 442 to TBmanager™.

The selected source code file can also be analyzed statically and/orinteractively for conformance with project coding rules and qualitymetrics by selecting the Analyze Procedures button 440 and AnalyzeInteractively button 441, respectively. The LDRA Testbed™ tool can alsobe invoked to perform the static and/or interactive analysis of theselected source code file. If interactive analysis is desired, the usercan perform code review, quality review, and design review analysis.Upon completion of the analysis, the map procedures GUI 438 can displaythe identified procedures 442 found in the selected source code file.Using the Map to Current Requirement button 444, the user can mapparticular identified procedures 442 to the current requirement, whichcan be selected using the Current Requirement drop-down menu or theProject Tree 412 via the project GUI 408. Similarly, the Unmap Selectedbutton 443 can be selected to unmap particular identified procedures 442from the current requirement. Having mapped procedures to requirements,the user can select the Procedures tab to view a list of the proceduresmapped to the current requirement.

Procedures View

The user can select a mapped procedure of a current requirement and viewits corresponding input and output (I/O) variables via a procedures GUI445, shown in FIG. 4H. The procedures GUI 445 includes a SelectProcedure drop-down menu 446, which can be used to select a procedurefrom those procedures that are mapped to the current requirement. Thecurrent requirement can be selected from the Current Requirementdrop-down menu or from the Project Tree 412 via the project GUI 408. Asa result of selecting a mapped procedure, the procedures GUI 445 can beupdated to display the I/O variables of the selected mapped procedure inthe I/O Variables field 447. Additionally, the procedures GUI 445includes a Desired Coverage field 449, which can be used to modify thedesired code coverage values (e.g., Statement, Branch, MC/DC, and Pathcoverage values) for the current requirement, and a Coverage Achieved atVerification field 450, which can be used to view the achieved coverageafter unit testing. The Unmap This Procedure button 448 can be selectedto unmap the selected mapped procedure from the current requirement.

Once procedures have been mapped to requirements, unit testing can beinitiated. First, a requirement having mapped procedures to be testedcan be selected either from the Project Tree 412 or the CurrentRequirement drop-down menu 409 via the project GUI 408. Next, toinitiate the unit test, the source code file containing the proceduresthat are mapped to the selected requirement can be selected, followed bythe Unit Test button 410 f. An external unit test tool can then beinvoked to perform the unit test. For example, LDRA TBrun™ is a unittest tool that can be invoked via the LDRA Testbed™ tool. Using theexternal test tool, test cases for the mapped procedures can be created.A mapped procedure to be tested can then be selected, inputs andexpected outputs for the test case can be entered, and the test case canbe run.

If results of the test case(s) are satisfactory and desired codecoverage is achieved, completion of requirement verification should beconfirmed. At least one test case for each mapped procedure for arequirement should be performed before confirming completion ofrequirement verification. After closing the external unit test tool,TBmanager™ can refresh the Project Tree 412 to display the requirementas verified (e.g., the corresponding requirements icon can be displayedwithout the “X” symbol). The project manager can now review the unittest information for the project to assess the users' work.

Verification View

Once a user has performed unit testing on the mapped procedure(s) for arequirement, the requirement can be displayed as “verified” in theProject Tree 412, shown in the project GUI 408. Because the unit testingof the mapped procedure(s) may not have achieved the desired coverage,however, the project manager, or other user(s) having the necessarypermission, should review the results of the unit testing and decidewhether the requirement should actually be considered verified.

Depending on the permissions assigned to a user, the user can verifywhether a requirement has met the desired code coverage by selecting theVerification tab to access a verification GUI 451, shown in FIG. 4I. Toverify a requirement, the user can select the requirement to be verifiedfrom the Project Tree 412 via the project GUI 408 or from the CurrentRequirement drop-down menu via the verification GUI 451. Theverification GUI 451 includes a Details field 453 displaying the currentstatus of the selected requirement 452. The Details field 453 indicatesthe user assigned to the selected requirement 452 and their role, theexpected code coverage, and the achieved code coverage, which can bedisplayed according to percentages of mapped procedures achieving thedesired coverage. If the user is satisfied with the coverage achievedfor the selected requirement the user can press the Verify button 454 tomaintain the current status of the selected requirement as verified.However, if the user is unsatisfied with the coverage achieved for theselected requirement, the user press the Un-verify button 455 to changethe current status of the selected requirement to unverified. Becauseun-verifying a requirement modifies that requirement, the user shouldupdate any sub-projects associated with the requirement.

With respect to verification of sibling requirements, a siblingrequirement acts much like a low-level requirement. That is, in orderfor a base requirement to be considered verified, all of its siblingrequirements must be verified first. For example, if a developer userhas been assigned a low-level requirement having two siblingrequirements, one for an IVV user and another for a QA user, thedeveloper cannot indicate the low-level requirement is verified untilthe IVV and QA users indicate the corresponding sibling requirements areverified.

A exemplary usage scenario for TBmanager™ is as follows. First, theproject manager can set-up a project based on captured high-levelrequirements, create low-level, derived and sibling requirements (ifappropriate), and assign requirements to users. Users can check-outtheir respective sub-projects, established when the project managerassigns requirements to the users. That is, the users can make a copy oftheir sub-projects for the purpose of performing remote operations onthe sib-projects. Users can modify the sub-project by mapping proceduresand testing and analyzing source code, among other tasks. Users can thencheck-in their modified sub-projects. That is, the users can copy theupdated contents of the sub-projects back into the project's directorytree. The project manager can subsequently log-in and obtain a completeand current view of all aspects of the project.

Defect View

FIG. 4J illustrates a GUI 456 that can be displayed when the Defect tabis selected. In one embodiment, a user can track defects in source codefor the project via the defects GUI 456. For example, the defects GUI456 can be used to track defects (i.e., non-conformances) in source codebased on the results of the analyses performed by the static analysistool. As shown in FIG. 4J, the user can add a defect to be tracked byselecting the “Add Defect” button 457. Added defects 458 are displayedwith information about the defect, including, for example, a defectnumber, date created, status, and user assigned to the defect, as wellas information regarding disposition of the defect. Added defects 458can be also be selected for editing.

CONCLUSION

The present invention has been described with reference to severalexemplary embodiments, however, it will be readily apparent to personsof skill in the relevant art(s) that it is possible to embody theinvention in specific forms other than those of the exemplaryembodiments described above. This may be done without departing from thescope of the invention. These exemplary embodiments are merelyillustrative and should not be considered restrictive in any way. Thescope of the invention is given by the appended claims, rather than thepreceding description, and all variations and equivalents which fallwithin the range of the claims are intended to be embraced therein.

What is claimed is:
 1. A method for ensuring traceability betweensoftware requirements and test cases, comprising: storing, in a testingdatabase, a plurality of test case data entries, wherein each test casedata entry includes at least a test case associated with a softwareprogram and one or more test attributes associated with the test case;receiving, by a receiving device, a plurality of software requirements,wherein each software requirement is a requirement associated with thesoftware program; identifying, by a processing device, at least one testcase data entry for each software requirement of the plurality ofsoftware requirements associated with the respective softwarerequirement based on the one or more test attributes included each ofthe associated at least one test case data entry; executing, by theprocessing device, the test case included in each of the plurality oftest case data entries using the software program, wherein executingeach test case produces a pass or fail result; and transmitting, by atransmitting device, data associated with the at least one test casedata entry associated with each software requirement of the plurality ofsoftware requirements, wherein the transmitted data includes at leastthe pass or fail result produced for the included test case.
 2. Themethod of claim 1, wherein the requirements associated with the softwareprogram are based on one or more industry standards.
 3. The method ofclaim 1, further comprising: analyzing, by the processing device, theproduced pass or fail result for each test case included in each testcase data entry associated with a software requirement of the pluralityof software requirements to determine a code coverage of the softwareprogram.
 4. The method of claim 3, further comprising: transmitting, bythe transmitting device, the determined code coverage of the softwareprogram.
 5. The method of claim 1, wherein the testing database,receiving device, processing device, and transmitting device areincluded in a first module of a computing device, and the plurality ofsoftware requirements are received from a second module of the computingdevice.
 6. The method of claim 5, wherein the second module is asoftware requirements traceability tool.
 7. The method of claim 7,wherein the software requirements traceability tool includes one of:IBM® Rational® DOORS®, IBM® Rational® RequisitePro®, and DassaultSystèmes® Reqtify®.
 8. A system for ensuring traceability betweensoftware requirements and test cases, comprising: a testing databaseconfigured to store a plurality of test case data entries, wherein eachtest case data entry includes at least a test case associated with asoftware program and one or more test attributes associated with thetest case; a receiving device configured to receive a plurality ofsoftware requirements, wherein each software requirement is arequirement associated with the software program; a processing deviceconfigured to identify at least one test case data entry for eachsoftware requirement of the plurality of software requirementsassociated with the respective software requirement based on the one ormore test attributes included each of the associated at least one testcase data entry, and execute the test case included in each of theplurality of test case data entries using the software program, whereinexecuting each test case produces a pass or fail result; and atransmitting device configured to transmit data associated with the atleast one test case data entry associated with each software requirementof the plurality of software requirements, wherein the transmitted dataincludes at least the pass or fail result produced for the included testcase.
 9. The system of claim 8, wherein the requirements associated withthe software program are based on one or more industry standards. 10.The method of claim 1, wherein the processing device is furtherconfigured to analyze the produced pass or fail result for each testcase included in each test case data entry associated with a softwarerequirement of the plurality of software requirements to determine acode coverage of the software program.
 11. The system of claim 10,wherein the transmitting device is further configured to transmit thedetermined code coverage of the software program.
 12. The system ofclaim 8, wherein the testing database, receiving device, processingdevice, and transmitting device are included in a first module of acomputing device, and the plurality of software requirements arereceived from a second module of the computing device.
 13. The system ofclaim 12, wherein the second module is a software requirementstraceability tool.
 14. The system of claim 13, wherein the softwarerequirements traceability tool includes one of: IBM® Rational® DOORS®,IBM® Rational® RequisitePro®, and Dassault Systèmes® Reqtify®.
 15. Anon-transitory computer-readable recording medium configured to storeprogram code executable by a processor of a computing device, whereinexecution of the program code is configured to cause the computingdevice to perform a method for ensuring traceability between softwarerequirements and test cases, comprising: storing, in a testing database,a plurality of test case data entries, wherein each test case data entryincludes at least a test case associated with a software program and oneor more test attributes associated with the test case; receiving, by areceiving device, a plurality of software requirements, wherein eachsoftware requirement is a requirement associated with the softwareprogram; identifying, by a processing device, at least one test casedata entry for each software requirement of the plurality of softwarerequirements associated with the respective software requirement basedon the one or more test attributes included each of the associated atleast one test case data entry; executing, by the processing device, thetest case included in each of the plurality of test case data entriesusing the software program, wherein executing each test case produces apass or fail result; and transmitting, by a transmitting device, dataassociated with the at least one test case data entry associated witheach software requirement of the plurality of software requirements,wherein the transmitted data includes at least the pass or fail resultproduced for the included test case.
 16. The non-transitorycomputer-readable recording medium of claim 15, wherein the requirementsassociated with the software program are based on one or more industrystandards.
 17. The non-transitory computer-readable recording medium ofclaim 15, wherein the method further comprises: analyzing, by theprocessing device, the produced pass or fail result for each test caseincluded in each test case data entry associated with a softwarerequirement of the plurality of software requirements to determine acode coverage of the software program.
 18. The non-transitorycomputer-readable recording medium of claim 17, wherein the methodfurther comprises: transmitting, by the transmitting device, thedetermined code coverage of the software program.
 19. The non-transitorycomputer-readable recording medium of claim 15, wherein the testingdatabase, receiving device, processing device, and transmitting deviceare included in a first module of the computing device, and theplurality of software requirements are received from a second module ofthe computing device.
 20. The non-transitory computer-readable recordingmedium of claim 19, wherein the second module is a software requirementstraceability tool.
 21. The non-transitory computer-readable recordingmedium of claim 20, wherein the software requirements traceability toolincludes one of: IBM® Rational® DOORS®, IBM® Rational® RequisitePro®,and Dassault Systèmes® Reqtify®.